Если вы на своем Mac решили установить VMware ESXi 7 в виртуальной машине на флешке, то с настройками по умолчанию этого сделать не получится - USB-устройство не обнаружится установщиком и не будет видно в разделе настроек USB & Bluetooth виртуальной машины.

Eric Sloof написал, что перед развертыванием ESXi, чтобы установщик увидел USB-диск, нужно перевести USB Compatibility в режим совместимости с USB 3.0:

После этого можно будет выбрать ваш USB-диск для установки ESXi 7.0:

Как вы все знаете, недавно компания VMware сделала доступной для загрузки платформу VMware vSphere 7, где службы управляющего сервера vCenter доступны уже только в формате виртуального модуля vCenter Server Appliance (vCSA).

Блоггер Ozan Orcunus написал интересную заметку о том, как можно отключить автозагрузку некоторых сервисов в vCenter 7. Не секрет, что с каждой новой версией vCenter становится все более и более прожорливым в отношении системных ресурсов. Например, для 10 хостов ESXi и 100 виртуальных машин теперь уже требуется сделать vCSA с двумя vCPU и 12 ГБ оперативной памяти, что слишком много для тестовых окружений, например, на ноутбуке.

Поэтому чтобы vCSA работал немного побыстрее в тестовых средах (и только там, в продакшене этого делать не рекомендуется) можно отключить некоторые его службы при загрузке. В KB 2109881 написано, как останавливать и запускать службы vCenter с помощью команды service-control, но нигде официально не написано о том, как отключать их при старте vCenter.

А делается это следующим образом:

1. Логинимся по SSH на сервер vCSA и переходим в каталог /etc/vmware/vmware-vmon/svcCfgfiles/.

2. Большинство сервисов vCenter - это не стандартные сервисы systemd, а службы спрятанные за за сервисом VMware Service Lifecycle Manager (vmware-vmon). Наберите "systemctl status vmware-vmon" и посмотрите на результат:

Конфигурация сервисов спрятана в JSON-файлах - в директориях, которые можно увидеть в выводе команды. Например, чтобы отключить службу Content Library, нужно открыть файл конфигурации командой:

vi vdcs.json

И выставить в нем параметр StartupType как DISABLED.

3. После внесения всех необходимых изменений нужно перезагрузить vCSA для применения настроек автозапуска.

4. После этого идем в раздел Services и видим, что автозапуск некоторых служб vCenter отключен:

Не все в курсе, но одной из новых возможностей обновленной платформы виртуализации VMware vSphere 7 стала поддержка протокола точной синхронизации времени PTP (Precision Time Protocol) для хост-серверов ESXi и виртуальных машин.

С давних пор для синхронизации времени в виртуальных машинах VMware vSphere использует протокол NTP, который обеспечивает точность синхронизации на уровне миллисекунд. Для большинства систем этого вполне достаточно, но есть и класс систем, где нужна точность на уровне микросекунд при обработке последовательности событий - например, для финансовых приложений, торгующих на бирже, где важен порядок ордеров в стакане.

Abhijeet Deshmukh написал про PTP в vSphere интересную статью, основные моменты которой мы приведем ниже.

Протокол NTP обладает следующими особенностями:

• Имеет точность на уровне единиц миллисекунд.
• Реализуется полностью программно, как для таймстемпинга приема сигналов точного времени, так и для таймстемпинга пользовательского уровня для передачи событий.
• Широко распространен и является индустриальным стандартом синхронизации времени.
• Работает несколько десятилетий, дешев, прост и надежен.
• Клиенты NTP включены во все компьютеры, серверы и роутеры, а также множество программных продуктов.
• Может синхронизировать время от самых разных источников - атомные часы, GPS-ресиверы, а также разные серверы, разбросанные по интернету.
• Клиент-серверная архитектура, позволяющая использовать несколько серверов для синхронизации.
• Возможности коррекции и отказоустойчивости - клиент может забирать время с нескольких серверов и исключать из них тот, который находится географически далеко и отвечает с задержкой сигнала.
• NTP - это юникаст-протокол, который не требует особых правил маршрутизации. Пакеты получает только источник и отправитель.

Для виртуальных машин у NTP есть следующие особенности:

• Сервер ESXi имеет встроенную поддержку NTP на уровне стандарта, а также имеет необходимые компоненты для его поддержки в kernel API.
• NTP работает на порту 123.
• NTP бесшовно работает для клиентов-виртуальных машин, где ОС поддерживают эту интеграцию.
• Как правило проблем с NTP не возникает для гостевых ОС, за исключением некоторых ситуаций, когда, например, вы делаете Suspend виртуальной машины.
• Виртуализация добавляет дополнительные уровни абстракции (например, vNIC), которые потенциально могут повлиять на часы гостевой ОС и переменные синхронизации.

Кстати, о проблеме управления временем в виртуальной инфраструктуре есть отличный документ "Timekeeping in
VMware Virtual Machines". Кроме того, полезно будет прочитать и вот эту статью.

Давайте теперь посмотрим на особенности протокола PTP (IEEE 1588):

• PTP работает на уровне точности в микросекундах, для чего используется механизм Hardware time stamping (это специальные сетевые адаптеры с поддержкой PTP).
• PTP, определенный стандартом IEEE 1588-2008, работает за счет обмена сообщениями мастер-часов и слейв-часов.

Вот так это выглядит:

• Времена отправки и получения событий Sync и Delay_Request сохраняются как 4 таймстемпа T1-T4.
• Сообщения Follow_Up и Delay_Response используются для передачи записанных таймстемпов от мастер-часов к слейв, чтобы осуществить коррекцию времени.
• По окончании передачи слейв-часы имеют все 4 таймстемпа. Это позволяет посчитать смещение от мастера и скорректировать слейв-часы по формуле: Offset = (T2 + T3 – T1 – T4) /2
• PTP в основном используется для обслуживания финансовых транзакций, передачи на уровне телефонных вышек, подводных систем позиционирования и прочих систем реального времени, где требуется высокая точность времени.
• PTP поддерживает отказоустойчивость. Если мастер-часы отказывают, то другой мастер принимает на себя его функции, так как находится в постоянном ожидании. Это реализовано средствами алгоритма Best Master Clock (BMC).
• PTP работает как мультикаст, а значит генерирует дополнительный трафик и требует специальные правила для его перенаправления между сегментами сети.
• Использует 2 UDP-порта - 319 и 320.
• В виртуальной машине для поддержки PTP есть специальное устройство precision clock для получения системного времени хоста.
• В рамках одной сети через PTP все ее виртуальные машины получают точное время.

В итоге можно сделать следующие выводы об использовании протоколов NTP и PTP в виртуальной инфраструктуре:

• Если у вас нет специальных задач под PTP, то старого доброго NTP вполне достаточно. Он надежный и отказоустойчивый.
• Для PTP нужно специальное оборудование, появляется мультикастовый трафик, и требуется изменение сетевых настроек, что вызывает необходимость в дополнительных затратах по настройке инфраструктуры. Очевидно, что развертывать его нужно только в случае появления у приложений в виртуальных машинах требования к точности времени на уровне микросекунд.

Как все уже знают, VMware vSphere 7 вышла, доступна для скачивания и уже обкатывается многими администраторами виртуальных инфраструктур. Для тех, кто еще не знает, поддерживает ли текущее оборудование новый гипервизор ESXi 7, Florian Grehl сделал специальный сценарий PowerCLI, который позволяет вывести эту информацию для серверов кластера:

Сценарий доступен в репозитории на GitHub. Скрипт автоматически загружает функцию HCL-Check (из GitHub), а также JSON-файл для VMware HCL. В переменной $scope можно установить серверы, которые будут проверены (по умолчанию проверяется все окружение vCenter).

Надо понимать, что если ваш хост не поддерживается для VMware ESXi 7, то имеет смысл проверить его еще раз на всякий случай в реальном VMware HCL.

Если вы получаете вот такое сообщение об ошибке:

.\check_esxi_70_support.ps1 : File .\check_esxi_70_support.ps1 cannot be loaded. The file is not digitally signed. You cannot run this script on the current system. For more information about running scripts and setting execution policy, see about_Execution_Policies at http://go.microsoft.com/fwlink/?LinkID=135170.

Значит нужно в свойствах скрипта разблокировать его:

В блоге VMware vSphere появилась интересная запись о том, как происходит работа с памятью в гипервизоре VMware ESXi. Приведем ее основные моменты ниже.

Работа виртуальной машины и ее приложений с памятью (RAM) идет через виртуальную память (Virtual Memory), которая транслируется в физическую память сервера (Physical Memory). Память разбита на страницы - это такие блоки, которыми виртуальная память отображается на физическую. Размер этого блока у разных систем бывает разный, но для ESXi стандартный размер страниц равен 4 КБ, а больших страниц - 2 МБ.

Для трансляции виртуальных адресов в физические используется таблица страниц (Page Table), содержащая записи PTE (Page Table Entries):

Записи PTE хранят в себе ссылки на реальные физические адреса и некоторые параметры страницы памяти (подробнее можно почитать здесь). Структуры записей PTE могут быть разного размера - это WORD (16 bits/2 bytes), DWORD (32 bits/4 bytes) и QWORD (64 bits/8 bytes). Они адресуют большие блоки адресов в физической памяти, к примеру, DWORD адресует блок адресов 4 килобайта (например, адреса от 4096 до 8191).

Память читается и передается гостевой системе и приложениям страницами по 4 КБ или 2 МБ - это позволяет читать содержимое ячеек памяти блоками, что существенно ускоряет быстродействие. Естественно, что при таком подходе есть фрагментация памяти - редко когда требуется записать целое число страниц, и часть памяти остается неиспользуемой. При увеличении размера страницы растет и их фрагментация, но увеличивается быстродействие.

Таблицы страниц (а их может быть несколько) управляются программным или аппаратным компонентом Memory Management Unit (MMU). В случае аппаратного MMU гипервизор передает функции по управлению трансляцией ему, а программный MMU реализован на уровне VMM (Virtual Machine Monitor, часть гипервизора ESXi):

Важный компонент MMU - это буфер ассоциативной трансляции (Translation Lookaside Buffer, TLB), который представляет собой кэш для MMU. TLB всегда находится как минимум в физической памяти, а для процессоров он часто реализован на уровне самого CPU, чтобы обращение к нему было максимально быстрым. Поэтому обычно время доступа к TLB на процессоре составляет около 10 наносекунд, в то время, как доступ к физической памяти составляет примерно 100 наносекунд. VMware vSphere поддерживает Hardware MMU Offload, то есть передачу функций управления памятью на сторону MMU физического процессора.

Итак, если от виртуальной машины появился запрос на доступ к виртуальному адресу 0x00004105, то этот адрес разбивается на адрес виртуальной страницы (Virtual page number - 0x0004) и смещение (Offset - 0x105 - область внутри страницы, к которой идет обращение):

Смещение напрямую передается при доступе к физической странице памяти, а вот тэг виртуальной страницы ищется в TLB. В данном случае в TLB есть запись, что соответствующий этому тэгу адрес физической страницы это 0x0007, соответственно трансляция виртуальной страницы в физическую прошла успешно. Это называется TLB Hit, то есть попадание в кэш.

Возможна и другая ситуация - при декомпозиции виртуального адреса получаемый тэг 0x0003 отсутствует в TLB. В этом случае происходит поиск страницы в физической памяти по тэгу (страницу номер 3) и уже ее адрес транслируется (0x006). Далее запись с этим тэгом добавляется в TLB (при этом старые записи из кэша вытесняются, если он заполнен):

Надо отметить, что такая операция вызывает несколько большую задержку (так как приходится искать в глобальной памяти), и такая ситуация называется TLB Miss, то есть промах TLB.

Но это не самая плохая ситуация, так как счет latency все равно идет на наносекунды. Но доступ может быть и гораздо более долгий (миллисекунды и даже секунды) в том случае, если нужная гостевой ОС страница засвопировалась на диск.

Посмотрим на пример:

Виртуальная машина обратилась к виртуальному адресу 0x00000460, для которого есть тэг 0x0000. В физической памяти для этого тэга выделена страница 0, которая означает, что искать эту страницу нужно на диске, куда страница была сброшена ввиду недостатка физической оперативной памяти.

В этом случае страница восстанавливается с диска в оперативную память (вытесняя самую старую по времени обращения страницу), ну и далее происходит трансляция адреса к этой странице. Эта ситуация называется отказ страницы (Page Fault), что приводит к задержкам в операциях приложения, поэтому иногда полезно отслеживать Page Faults отдельных процессов, чтобы понимать причину падения быстродействия при работе с памятью.

Cody Hosterman, известный своими заметками про PowerCLI, написал интересную статью о том, как запоминать дефолтные параметры на примере свойств соединения с дисковым массивом. Это может вам оказаться полезным, например, в случае если вы работаете с дисковым массивом в интерактивном режиме, при этом не хотите каждый раз указывать параметры соединения.

К примеру, при использовании модуля PureStorage.FlashArray.VMware есть возможность передавать параметры соединения, сохраненные в глобальной переменной $Global:DefaultFlashArray. Неудобство этого метода в том, что каждый раз вы должны указывать параметр -Array:

Поэтому в PowerCLI заложен отличный механизм дефолтных параметров для нужных вам командлетов. Например, можно создать переменную с параметрами соединения с массивом:

$flasharray = new-pfaarray -endpoint 10.21.202.60 -credentials (get-credential) -ignoreCertificateError

Далее можно записать эту переменную в дефолтные параметры:

$PSDefaultParameterValues = @{
 "*-pfa*:Array"=$flashArray;

  }

Это позволит для параметра, называющегося Array применять параметры соединения из переменной $flashArray. При этом эти параметры будут применяться только для командлетов, содержащих "-pfa" в своем названии (они есть только в модуле PureStoragePowerShellSDK).

Для всего модуля и всех командлетов нет простого способа задать дефолтные параметры, но можно получить в сценарии список всех доступных командлетов и для всех них прописать правило использования параметра -Array:

$psCMDs = (get-command -Module PureStoragePowerShellSDK).Name

  $defaultParamHash = @{}

  foreach ($psCMD in $psCMDs)

  {

$defaultParamHash.Add("$($psCMD):Array",$flashArray)

}

$PSDefaultParameterValues = $defaultParamHash

После этого вы сможете просто использовать командлеты без параметров, например, Get-PfaVolumes, чтобы получить все тома с заданного в дефолтном соединении массива:

Аналогично способ будет работать и для всех остальных параметров командлетов и любых других модулей.

Как вы знаете, каждый год VMware раздает награды VMware vExpert тем, кто вносит вклад в развитие сообщества, собранного вокруг технологий виртуализации. Звание это присуждается уже довольно давно, его носителей стало так много, что появилась даже уже более узкая подкатегория vExpert Pro.

В России тоже набралось уже 10 человек носителей vExpert, не так много, но и не мало (на уровне Швеции и Норвегии). Понятное дело, что большинство vExpert из тех стран, где все хорошо с английским, так как аудитория блогов на английском языке шире, что мотивирует авторов писать посты (а в целом vExpert дают за ведение блога).

Вот так выглядит первая десятка:

А вот те специалисты из России, кто получил vExpert в этом году:

Полный список получателей vExpert опубликован тут.

Как знают многие администраторы, во время установки vCenter Server Appliance (vCSA) для управления виртуальной инфраструктурой изменить MAC-адрес управляющего сервера нельзя - он генерируется при развертывании виртуального модуля установщиком и прописывается внутрь конфигурации. Между тем, если вам это все-таки по каким-то причинам требуется, Вильям Лам привел способ, как это сделать.

Ниже приведена процедура развертывания vCSA с сервера VMware ESXi.

Во-первых, надо преобразовать OVA-модуль в формат OVF, где можно будет потом изменить настройки. Делается это с помощью утилиты ovftool следующим образом:

ovftool --allowExtraConfig VMware-vCenter-Server-Appliance-6.7.0.42000-15132721_OVF10.ova VMware-vCenter-Server-Appliance-6.7.0.42000-15132721_OVF10.ovf

Сначала нам нужно добавить следующую конфигурацию в раздел Network конфигурации виртуального модуля OVF, содержащую нужный нам MAC-адрес:

<Item>

   <rasd:Address>00:50:56:ab:cd:ef</rasd:Address>

   <rasd:AutomaticAllocation>true</rasd:AutomaticAllocation>

   <rasd:Connection>Network 1</rasd:Connection>

   <rasd:ElementName xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData">Ethernet adapter on &quot;Network 1&quot;</rasd:ElementName>
   <rasd:InstanceID xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData">3</rasd:InstanceID>

   <rasd:ResourceSubType>vmxnet3</rasd:ResourceSubType>

   <rasd:ResourceType>10</rasd:ResourceType>

</Item>

Далее изменяем скрипт VCSAStaticMACAddress.sh на сервере ESXi, чтобы добавить туда нужные параметры вашего vCSA и начать его развертывание в вашей виртуальной среде. Для этого его нужно выполнить с параметром --injectOvfEnv, про который написано вот тут. Он позволяет внедрить свойства OVF в виртуальный модуль vCSA при его включении.

Если вы все сделали правильно, то сможете наблюдать за прогрессом развертывания вашего виртуального модуля из браузера по ссылке:

https://[адрес VCSA]:5480

В итоге вы должны увидеть, что в настройках модуля vCSA вы получили нужный вам MAC-адрес:

Если вы хотите пропустить стадию конфигурации сетевых настроек (IP-адрес и прочее) при исполнении скрипта, нужно выставить переменную VCSA_STAGE1ANDSTAGE2 в значение false. Тогда после развертывания модуля vCSA нужно будет закончить его конфигурацию по ссылке:

https://[адрес VCSA]:5480

После развертывания эта возможность будет доступна на открывшейся странице:

Интересные вещи делает наш коллега Jorge de la Cruz. Он скрупулезно и дотошно делает полезные дэшборды в Grafana для платформы виртуализации VMware vSphere и решения Veeam Availability Suite, которые могут помочь администраторам в решении повседневных задач мониторинга и траблшутинга.

Вот эти дашборды:

• Grafana vSphere Overview Dashboard – 8159
• Grafana vSphere Datastore Dashboard – 8162
• Grafana vSphere Hosts Dashboard – 8165
• Grafana vSphere VMs Dashboard – 8168

Чтобы сделать доступными функции визуализации этих метрик, вам потребуется развернуть следующие компоненты:

• Коллектор и нативный плагин Telegraf к VMware vSphere - агент, который собирает метрики в кластере и сохраняет их в базе данных InfluxDB.
• InfluxDB - собственно, сама база данных, хранящая метрики.
• Grafana - фреймворк, который используется для визуализации метрик из базы.

О том, как это все заставить работать, чтобы получать красивые дашборды, подробно написано вот тут и тут. Ниже мы лишь приведем примеры того, как это выглядит:

1. vSphere Overview Dashboard.

Здесь визуализуются все высокоуровневые параметры виртуальной инфраструктуры, такие как загрузка ресурсов кластера, заполненность хранилищ, состояние гипервизора и использование ресурсов виртуальными машинами.

Лайв-демо такого дэшборда доступно по этой ссылке.

2. vSphere Datastore Dashboard.

Тут можно найти все метрики, касающиеся хранилищ, включая параметры чтения и записи, и многое другое:

Лайв-демо такого дэшборда доступно по этой ссылке.

3. vSphere Hosts Dashboard.

Тут видны основные метрики с уровня хоста для каждого из серверов ESXi: конечно же, загрузка аппаратных ресурсов и сети, а также дисковые задержки (latency):

Лайв-демо такого дэшборда доступно по этой ссылке.

4. vSphere VMs Dashboard.

Здесь можно увидеть самые полезные метрики для всех виртуальных машин вашего датацентра. Здесь можно увидеть аптайм, загрузку системных ресурсов и сети, latency, счетчик CPU Ready и другое:

Лайв-демо такого дэшборда доступно по этой ссылке.

5. vSphere Hosts IPMI dashboard.

Этот дэшборд отображает информацию IPMI для серверов Supermicro и HPE, доступную через iLO. Пригодится, когда вам нужно взглянуть на статус ваших систем в распределенной инфраструктуре удаленных офисов и филиалов.

Кроме приведенных выше дэшбордов для VMware vSphere, у Jorge de la Cruz также есть несколько дэшбордов для решений Veeam Software:

• Grafana Dashboard for Veeam Availability Console - SP Overview
• Grafana Dashboard for Veeam Availability Console - Tenant Overview
• Grafana Dashboard for Veeam Backup for Microsoft Office 365 v3.0
• Grafana Dashboard for Veeam Backup for Microsoft Office 365 v3.0 - Security and Performance
• Grafana Dashboard for Veeam Backup for Microsoft Office 365 v4

Ну в заключение, стоит отметить еще один дэшборд автора - Microsoft Azure Storage.

Большинство сценариев PowerCLI начинаются с команды Connect-VIServer. Она позволяет соединиться с нужным сервером VMware vCenter и исполнять там необходимые сценарии.

Если вы работаете только с одним сервером vCenter, то нужно лишь один раз соединиться с сервером и после этого выполнять там команды без его указания. Для удобства работы в таких окружениях разработчики обычно прописывают глобальную переменную $global:DefaultVIServer, где указывают сервер vCenter по умолчанию. Это дает возможность исполнять командлеты без указания сервера vCenter, который будет подставляться из глобальной переменной.

Если из сценария PowerCLI вы соединяетесь с несколькими серверами vCenter одновременно, то для выполнения команды на нужном vCenter, надо указать его явно:

Get-VM -Server vcenter1.domain.local

В то же время, если вы пользуетесь глобальной переменной DefaultVIServer, вы можете попасть в ситуацию, когда использование ее станет невозможным, поскольку она очищается при дисконнекте от сервера vCenter. Рассмотрим пример:

Connecting to vCenter server vcenter1.domain.local

DefaultVIServer value: vcenter1.domain.local

Connecting to vCenter server vcenter2.domain.local

DefaultVIServer value: vcenter2.domain.local

Disconnecting from vCenter server vcenter2.domain.local

DefaultVIServer value:

Get-VM : 29/11/2019 6:17:41 PM Get-VM You are not currently connected to any servers. Please connect first using a Connect cmdlet.

Мы видим, что при отключении от сервера vCenter2 произошла очистка переменной DefaultVIServer, поэтому при попытке вызвать командлет Get-VM возникла ошибка. При этом текст ошибки об отсутствии соединения вводит в заблуждение и не соответствует фактической ситуации. Ведь подключение к серверу vCenter1 осталось, просто отсутствует значение этого сервера в переменной DefaultVIServer.

Чтобы работать с несколькими серверами vCenter одновременно, в окружении PowerCLI есть режим Multiple DefaultVIServer mode, который позволяет использовать массив DefaultVIServers.

Перейти в этот режим можно командой:

Set-PowerCLIConfiguration -DefaultVIServerMode Multiple

После перехода в этот режим все команды без указания параметра -Server будут исполняться на всех подключенных серверах vCenter (это надо иметь в виду), присутствующих в массиве DefaultVIServers.

Если же другие пользователи будут выполнять ваш скрипт в режиме Single connection mode, то он может исполняться некорректно или вылететь с ошибкой, поэтому явно указывайте режим Multiple DefaultVIServer mode в самом начале скрипта.

На интересный момент обратил в своем блоге Mark Ukotic: ведь гостевая ОС Microsoft Windows Server 2019 недоступна при указании типа гостевой системы на платформе VMware vSphere:

Между тем, Windows Server 2019, вышедший еще в октябре прошлого года, полностью поддерживается в последних версиях VMware vSphere. Согласно статье KB 59222, для Windows Server 2019 нужно выбрать тип гостевой ОС Windows Server 2016 or later. Если подумать, это очень странно - ведь за прошедший с момента релиза год выходило немало апдейтов платформы VMware vSphere, хотя бы тот же vSphere 6.7 Update 3, но отдельной строчки для последней серверной платформы Microsoft в интерфейсе так и не появилось.

Однако если взглянуть на VMware Compatibility Guide и выбрать там в поле OS Family name систему Windows Server 2019, то мы увидим, что ESXi вполне ее поддерживает, начиная с версии 6.0.

Согласно политике поддержки VMware, если мы видим эту ОС в HCL, то она полностью поддерживается для работы в виртуальной машине на платформе vSphere.

То есть это чисто интерфейсная особенность, где поддержка Windows Server 2019 скрывается за окончанием пункта "or later".

Большинство из вас, конечно же, слышало о серии уязвимостей в процессорах Intel (например, Meltdown и Spectre), которые потенциально могли приводить к получению контроля над исполнением систем (в том числе виртуальных машин), работающих на базе определенных CPU. Об этом можно прочитать у нас, например, тут и тут.

При обнаружении таких уязвимостей Intel выпускает обновления микрокода (firmware) для своих процессоров, которые нужно применить как к серверам ESXi, так и к виртуальным машинам. Например, для устранения уязвимости типа MDS была добавлена инструкция MD_CLEAR, которую гостевая ОС может обнаружить и использовать для защиты от определенных уязвимостей.

В виртуальной среде виртуальная машина - это VMX-процесс на сервере ESXi, который обеспечивает исполнение гостевой операционной системы. При этом ВМ может перемещаться между серверами ESXi средствами vMotion, поэтому она может иметь довольно большой аптайм (больше самих хостов, где она работает) и, как следствие, долго не обновлять виртуальное аппаратное обеспечение.

В то же время, для патчинга некоторых уязвимостей нужно обновить микрокод CPU и пересоздать VMX-процесс виртуальной машины, чтобы она могла инициализировать и подхватить обновления микрокода (что происходит только при первой загрузке). Простая перезагрузка тут не поможет, так как в этом случае пересоздания VMX не происходит, а лишь идет ребут гостевой системы. Кстати, это вам на заметку - если хотите "почистить" виртуальную машину, то лучше выключить и включить ее, а не перезагружать.

Чтобы выполнить процедуру выключения и включения, начиная с vSphere 6.5 Update 3 и vSphere 6.7 Update 3, компания VMware ввела инструкцию vmx.reboot.PowerCycle, которая выполняет цикл питания виртуальной машины. Этот параметр, который можно добавить в VMX-файл, считывается со стороны VMware Tools, которые уже совместно с хостом ESXi обеспечивают исполнение этого цикла.

Чтобы добавить этот параметр в VMX-файл через PowerCLI, вы можете использовать следующую команду:

New-AdvancedSetting -Entity YOUR_VM_NAME -Name vmx.reboot.PowerCycle -Value TRUE -Confirm:$false

Это же можно сделать и для групп виртуальных машин, например, находящихся в папке Test Group 1:

Get-Folder "Test Group 1" | Get-VM | New-AdvancedSetting -Name vmx.reboot.PowerCycle -Value TRUE -Confirm:$false

Эти команды можно сопроводить принудительным флагом исполнения -Force и контролировать поведение в случае ошибки с помощью -ErrorAction.

После того, как параметр PowerCycle будет выставлен, VMware Tools (вы же помните, что они должны быть установлены) смогут совершить цикл сброса питания для виртуальной машины, а затем сам параметр будет удален из VMX-файла. Также он будет удален автоматически, если вы вручную завершите и снова запустите виртуальную машину.

Для контроля того, что параметр установлен, вы можете посмотреть в vSphere Client, в разделе Configuration Parameters (в самом низу):

Также использование данного параметра может вам помочь в случае кластеров Enhanced vMotion Compatibility (EVC). Такие кластеры требуют от виртуальных машин поддержки единого базового уровня инструкций CPU для обеспечения vMotion между хостами с разным аппаратным обеспечением.

В случае, если у вас где-то поменялось железо на хостах, то нужно выполнить перезапуск цикла питания виртуальных машин, что приведет кластер EVC к единому базовому уровню и позволит избавиться от потенциальных проблем.

Некоторое время назад мы писали о новых возможностях продукта VMware vCloud Director 10.0, которые раскрыл Daniel Paluszek. На днях он сделал еще очень полезную диаграмму, которая раскрывают логику миграции на vCD 10 с предыдущих версий.

Daniel использовал утилиту MindNode для составления данной диаграммы апгрейда на vCD 10. Как видно на картинках, там описаны разные варианты исходной системы, например, вы решите пойти по пути обновления только Linux / External PostgreSQL (PgSQL) с раздельной инсталляцией vCD или сделаете интегрированные виртуальные модули vCloud Director.

Диаграмма доступна как с фоном, так и с прозрачностью PNG-формата:

Для Linux-систем Daniel отмечает следующие моменты:

1. vCD 10.0 поддерживает только PostgreSQL, у него нет больше поддержки Microsoft SQL Server. Oracle уже прекратил поддерживаться ранее, поэтому все пути миграции ведут на PgSQL в данных диаграммах.
2. Использование виртуального модуля vCD позволяет обеспечить высокую доступность PgSQL, но в случае сбоя нужно будет вручную переключаться на реплику.
3. Использование внешнего экземпляра PostgreSQL полностью поддерживается. Но нужно внимательно следить за конфигурацией соединения к БД.
4. VMware будет продолжать поставлять как установщик, так и виртуальный модуль vCD. Поэтому можно использовать оба варианта, в зависимости от нужд вашей команды.

Более подробно о данных диаграммах можно почитать у Daniel Paluszek.

Некоторое время назад мы писали о новых возможностях решения для создания отказоустойчивых хранилищ на базе хост-серверов VMware vSAN 6.7 Update 3. Среди прочего там появилось пара расширенных настроек, на которые обратил внимание Cormac Hogan. Давайте посмотрим, чем управляют эти Advanced Options в кластере.

Чтобы увидеть новые опции, надо в vSphere Client пойти в Cluster > Configure > vSAN > Services > Advanced Options, где можно увидеть параметры Large Cluster Support и Automatic Rebalance:

Первая настройка, как понятно из названия, регулирует возможность создания кластеров, которые имеют более 32 узлов. Ранее, чтобы расширить кластер, нужно было выставить параметр TcpipHeapMax на всех его хост-серверах ESXi. Теперь это удобно сделано в Advanced Options и применяется на уровне всего кластера.

Настройка Large Cluster Support требует перезагрузки каждого из хост-серверов:

Если вы не перезагрузите хосты, что в разделе статуса "vSAN extended configuration in sync" будут отображаться ошибки:

Вторая настройка, Automatic Rebalance, относится к дисковым объектам кластера vSAN, которые распределяются по дисковым группам разных хостов. Если данная настройка включена, то кластер vSAN автоматически наблюдает за балансом распределения дисковых объектов по хостам ESXi и выравнивает нагрузку на дисковые устройства. По умолчанию пороговое значение составляет 30%, что означает, что когда разница нагрузки между двумя дисковыми устройствами достигнет этого значения - начнется перебалансировка и перемещение дисковых объектов. Она будет продолжаться, пока это значение не снизится до 15% или меньшей величины.

Также в разделе vSAN Disk Balance вы найдете информацию по использованию дисковой подсистемы кластера:

В случае, если у вас включена настройка Automatic Rebalance, кластер vSAN будет стараться поддерживать этот хэлсчек всегда зеленым. Если же отключена - то в случае возникновения дисбаланса загорится алерт, и администратору нужно будет вручную запустить задачу Rebalance Disks.

Многим администраторам знакома такая вещь: сначала для теста устанавливается виртуальная машина VMware vCenter Server Appliance в конфигурации tiny (минимальные аппаратные настройки), а потом она приживается, и хочется сделать из нее полноценную производственную среду управления (конфигурацию large). Только вот не хочется ее переустанавливать.

Для тех, кто столкнулся с такой проблемой, Robert Szymczak написал полезный пост о том, как это сделать (но помните, что это неофициальная и неподдерживаемая процедура).

Установщик vCSA использует фреймворк Electron, настраивая конфигурацию через JSON, и механизм JSON-Schema для установки и валидации параметров. Поэтому в ISO-образе вы сможете найти конфигурацию сервера vCenter по следующему пути:

\vcsa-ui-installer\win32\resources\app\resources\layout.json

Там как раз и находятся данные о типовых конфигурациях vCSA. Например, так выглядит размер xlarge:

"xlarge": {
        "cpu": 24,
        "memory": 49152,
        "host-count": 2000,
        "vm-count": 35000,
        "disk-swap": "50GB",
        "disk-core": "100GB",
        "disk-log": "25GB",
        "disk-db": "50GB",
        "disk-dblog": "25GB",
        "disk-seat": "500GB",
        "disk-netdump": "10GB",
        "disk-autodeploy": "25GB",
        "disk-imagebuilder": "25GB",
        "disk-updatemgr": "100GB",
        "disk-archive": "200GB",
        "required-disk-space": "1180GB",
        "label": "X-Large vCenter Server with Embedded PSC",
        "description": "This will deploy a X-Large VM configured with 24 vCPUs and 48 GB of memory and requires 1180 GB of disk space will be updated for xlarge later. This option contains vCenter Server with an embedded Platform Services Controller for managing up to 2000 hosts and 35,000 VMs."
    }

Таким образом вы поймете, на какие именно конфигурации нужно изменить компоненты виртуальной машины с vCenter. Перед изменением конфигурации сделайте снапшот машины vCSA, который сохранит параметры ее виртуального аппаратного обеспечения.

Теперь переходим, собственно, к изменению самой конфигурации:

1. Увеличение CPU и памяти (RAM).

• Остановите машину.
• Хорошая идея - вывести ее ESXi-хост из кластера DRS.
• Зайдите на ESXi через Host Client, после чего в настройках ВМ измените конфигурацию CPU и памяти, чтобы выставить ее в соответствии с нужной конфигурацией.

2. Увеличение диска ВМ с сервером vCSA.

• Об увеличении дискового пространства сервера vCSA 6.5 мы писали вот в этой статье. С тех пор ничего особо не изменилось. Некоторую дополнительную информацию вы также можете получить в KB 2145603 на случай если что изменится в процедуре vCSA 6.x.
• Диски нужно настраивать не только по размеру, но и по корректной позиции в виртуальном слоте SCSI.

Примерно так это выглядит для vCenter 6.7 Update 2:

Помните, что иногда имя VMDK может не соответствовать его позиции в слоте SCSI. Например, встречаются случаи, когда VMDK0 смонтирован в слот SCSI(0:4), а VMDK2 - в слот SCSI(0:0). В этом случае реальным загрузочным диском будет VMDK2, а не VMDK0, несмотря на их названия.

Также обратите внимание, что SCSI слот 0:7 не используется - не ошибитесь.

После изменения этих параметров запустите vCenter и убедитесь, что все в порядке.

Коллеги из Veeam Software попросили помочь в поиске человека, который будет заниматься контент-маркетингом в сфере защиты данных и обеспечения доступности виртуальных датацентров. Надо писать тексты, хорошие заголовки и брифы, а также говорить на английском (и, желательно, испанском) языке.

Veeam представлять не требуется - это один из лидеров петербургского (а сейчас уже международного) ИТ-рынка, компания которая стоит не менее 5 миллиардов долларов. Внутри отличная корпоративная атмосфера (просто потому, что стараются брать на работу адекватных людей) и возможности релокации по всему миру (если вам такое интересно). Можно переехать в Чехию, в Америку, в Бухарест, да и вообще много куда.

Ссылка на вакансию - https://careers.veeam.ru/vacancies/it/writer-content-marketing-743999689524636

Собственно, само описание:

Writer, Content Marketing

Veeam Software is a global leader in intellectual data management based in more than 30 countries that serves 343,000+ customers all over the world.

Our clients are big and midsize business from different industries.  We help 82% Fortune 500 companies to evolve the way they manage data and to ensure it’s available across any application and across any cloud infrastructure.
We are trusted by: L’Oreal, PwC, Volvo, Gatwick, Scania and many more.

In a partnership with VMware и Microsoft we help business to improve.

• Английский

•  Create short texts, product descriptions, blog posts, white papers about Veeam solutions and data management industry in general - topics might include virtualization, data protection for both physical and virtual environments, cloud data management, server networking, data center infrastructure trends etc - with purpose of helping to drive organic and paid traffic to Veeam sites and raise awareness about Veeam solutions and thought leadership. 
• Publish content via WordPress on Veeam blogs or coordinate content publishing on 3rd party platforms.  
• Collaborate with external and internal subject matter experts (evangelists, bloggers, engineers, developers, analytics, IT administrators) on content topic development and content creation. 
• Collaborate with multiple teams across regions/departments to ensure aligned content production and promotion: product marketing, campaign management, digital advertisement, email marketing, SEO, localization, creatives, web-development etc. 
• Initiate and drive projects with creative and web-development teams to ensure effective content placement on Veeam and 3rd party web sites (mainly Veeam blog UX). 
• Use Google Analytics, MOZ and similar digital analytical tools to perform regular reporting on content activities results. 
• Maintain content publishing schedule for particular audiences/regions. 
• Work with tracking, planning and CRM systems for tasks management and analytics.

• Proven written and oral communication English and Spanish language skills, including business communications. 
• In-bound and out-bound digital marketing understanding. 
• Ability to learn quickly. 
• Strong interpersonal, writing, and verbal skills. 
• Must be able to work effectively both as a team member and independently. 
• Demonstrate ability to prioritize, multi-task, and work with minimal supervision in a team environment. 
• Strong organization skills with emphasis on being conscientious and detail-oriented. 
• Strong computer skills and proficiency in Word, Excel, Outlook and PowerPoint. 
• Technical understanding of data protection industry and virtualization principles. 
• Technical background (degree or work experience as network/support engineer or similar) and/or work experience in Digital Marketing is a strong plus. 
• Working knowledge of computer software such as VMware, Windows Server/Hyper-V or similar is a strong plus. 
• Experience in Google Analytics is a strong plus. 
• Basic understanding and/or experience of PPC, SEO, analytics and web-development is a strong plus.

• Work in a stable, dynamic company
• Modern energetic multinational working environment
• Interesting people, an excellent team of professionals
• Extensive opportunities for professional growth and career
• Flexible work schedule (work on European time)
• Employment according to the Labor Code of the Russian Federation, “white” salary
• An extended medical insurance policy
• Opportunity to join the Veeam footbal/lvolleyball team
• Partial compensation of costs on fitness
• Annual leave 28 days

Откликнуться на вакансию можно по этой ссылке.

Для многих пользователей публичного облака VMware vCloud on AWS одним из первых возникает вопрос - как предоставить доступ из виртуальной машины в сети Compute Network в сеть SDDC Management Network, например, для целей управления сервисами vCenter или другими службами виртуального датацентра?

Также этот вариант использования может быть востребован, когда вам требуется доступ к управляющим компонентам посредством таких интерфейсов, как PowerCLI, или развертывание виртуальных сервисов с помощью утилиты OVFTool. Вильям Лам написал об этом хорошую статью, и мы приведем здесь ее основные моменты.

Естественно, что для целей обеспечения безопасности в облаке, эти две сети по умолчанию разделены. Первое, что вам нужно сделать - это понять, с каким типом решения NSX для управления сетью вы работаете (NSX-T или NSX-V). Сделать это можно с помощью вот этой статьи.

Процедура для NSX-V

В среде NSX-V вам нужно настроить IPsec VPN между компонентами Management Gateway (MGW) и Compute Gateway (CGW) перед тем, как заработает коммуникация между сетями.

Для настройки VPN для компонента Management Gateway нажимаем Add VPN в консоли VMC и вводим требующуюся информацию сетевой идентификации (публичный IP удаленного шлюза, параметры удаленной сети и ключи), что должно отражать конфигурацию Compute Gateway (остальные настройки можно оставить по умолчанию).

Далее надо настроить VPN для Compute Gateway путем выполнения тех же шагов, что и в предыдущем абзаце, только указав конфигурацию шлюза Management Gateway. После того, как настройки обеих VPN будут сохранены, начнет отображаться статус "Partially Connected". Потом нажимаем ссылку Actions в правом верхнем углу, выбираем Edit и сохраняем настройки еще раз, чтобы на обоих шлюзах показался статус "Connected":

Теперь надо настроить сетевой экран Compute Gateway Firewall, чтобы разрешить исходящие соединения в SDDC Management Network по порту 443 для требуемых ВМ (этот порт используется для vSphere Client, а также для доступа через средства OVFTool и PowerCLI).

В приведенном ниже примере машина имеет адрес 192.168.1.4, и мы хотим позволить ей общаться с сетью 10.2.0.0/16 через порт 443:

Теперь нужно добавить в фаервол Management Gateway Firewall правила для разрешения входящих соединений для vCenter Server и хостов ESXi по порту 443 от наших определенных ВМ. Здесь все точно так же - указываем IP машины 192.168.1.4, и нам нужно добавить 2 правила для входящего трафика для разрешения коммуникации со средствами управления виртуальной инфраструктурой:

После этого вы можете залогиниться в виртуальную машину и использовать средства управления платформой vSphere, например, применять утилиту импорта виртуальных модулей OVFTool, как рассказано тут.

Процедура для NSX-T

В среде NSX-T вам не нужно создавать VPN для получения функциональности маршрутизации, которая изначально заложена в маршрутизаторе T0, ведь обе сети Management и Compute Network присоединены к T0. Между тем, правила сетевого экрана добавлять, конечно же, нужно.

В решении NSX-T используются сущности Inventory Groups, чтобы сгруппировать набор виртуальных машин и/или IP-адреса/сети, которые можно использовать при создании правил сетевого экрана.

Создаем две Inventory Groups для нашей Compute Group - одну для нашей виртуальной машины и одну для того, чтобы представлять сеть Management Network. Идем в Groups и в левой части выбираем пункт "Workload Groups", где создаем 2 группы:

• Windows10 с Member Type вида Virtual Machine и указываем ВМ из инвентаря.
• VMC Management Network с Member Type вида IP Address и указываем сетевой диапазон 10.2.0.0/16.

Теперь нужно создать еще одну Inventory Group для нашей Management Group, которая будет отражать ВМ, для которой мы хотим сделать доступ. Чтобы это сделать, идем в Groups, выбираем "Management Groups" и создаем следующую группу:

• Windows10 Private IP с Member Type вида IP Address и указываем частный IP-адрес ВМ (в данном случае это 192.168.1.2).

Не забывайте нажать кнопку Publish, чтобы сохранить и применить правило сетевого экрана.

Теперь нужно создать правило сетевого экрана, чтобы разрешить Compute Gateway исходящие соединения к SDDC Management Network по порту 443 для нужных ВМ. Идем в Gateway Firewall и выбираем "Compute Gateway", где создаем новое правило, которое отражает группу Windows 10 как источник и группу VMC Management Network как назначение, а в качестве сервиса выбираем HTTPS (помним также про кнопку Publish).

Теперь надо создать правила на уровне Management Gateway, чтобы разрешить входящие соединения к хостам vCenter Server и ESXi по порту 443 из нужных нам ВМ. Идем в Gateway Firewall, слева выбираем "Management Gateway", затем создаем правило, которое отражает группу Windows 10 как источник, а в качестве группы назначения указываем vCenter и ESXi (сервис ставим также HTTPS):

После выполнения этой процедуры вы сможете залогиниться в ВМ Windows и использовать утилиту OVFTool для импорта/экспорта ВМ в ваш виртуальный датацентр (см. также данную процедуру здесь).

Если все было сделано правильно, вы должны иметь возможность доступа к интерфейсу vSphere Client из нужной вам ВМ, а также возможность выполнять сценарии PowerCLI и использовать утилиту OVFTool, как показано на скриншоте ниже:

Если вы давно используете решение для организации инфраструктуры виртуальных ПК VMware Horizon, то, возможно, вам уже надоела картинка на бэкграунде формы доступа пользователей через веб-интерфейс:

Чтобы сменить эту картинку с облаками, на Connection Server идем в папку:

C:\Program Files\VMware\VMware View\Server\broker\webapps\portal\webclient\icons-6510409

Находим там файл bg_image и заменяем на новый (его разрешение 2560x1440):

Перезапускаем службу Horizon View Connection Server Service, после чего при заходе на View Connection Server через браузер мы увидим новый бэкграунд:

Очень дельную статью написал Вильям Лам, касающуюся настройки алармов для различных событий в инфраструктуре VMware vSphere. Иногда системному администратору требуется настроить мониторинг каких-либо действий пользователей, которые вызывают генерацию событий в консоли vSphere Client.

Например, вы хотите получать аларм, когда пользователь создает папку (Folder) для виртуального окружения через vSphere Client. Для начала нам понадобится информация, которую мы будем использовать в описании аларма. Для этого мы делаем действие, генерирующее событие, вручную (в данном случае, создаем папку), а после этого идем в раздел Monitor->Tasks, где смотрим описание задачи и связанного с ней события:

Главное здесь для нас - это лейбл "Task: Create folder", по которому мы найдем этот тип событий через PowerCLI, а точнее его Description Id. Открываем консоль PowerCLI и выполняем там вот такую команду, указав лейбл нашего события, найденный в консоли vSphere Client:

$createFolderEvents = Get-VIEvent | where {$_.GetType().Name -eq "TaskEvent" -and $_.FullFormattedMessage -eq "Task: Create folder" }
$createFolderEvents[0].Info.DescriptionId

Результатом будет Description Id нашего события - это Folder.createFolder:

Далее можно создавать аларм, зная Description Id события. Выбираем тип условия Task event, а также описание в виде Description Id, тип условия end with и сам этот ID - Folder.createFolder:

После создания такого аларма, при каждом создании папки он будет срабатывать, что можно увидеть в разделе Triggered Alarms:

Таким же образом вы можете настроить алармы и для любых других событий, происходящих в инфраструктуре VMware vSphere.

В конце прошлого года мы писали о новых возможностях VMware vCenter в составе обновленной платформы виртуализации VMware vSphere 6.7 Update 1. Среди прочих интересных фичей, vCenter 6.7 U1 получил функцию Health Сhecks, которая позволяет обрабатывать данные телеметрии виртуальной инфраструктуры и на основе экспертных алгоритмов вырабатывать рекомендации по ее улучшению. Например, если у вас одна сеть Management network, вам могут порекомендовать ее задублировать.

Вчера мы писали об общем устройстве механизма vSphere Health. Давайте теперь детально посмотрим, как именно это работает. Сделано это чем-то похоже на службы vSAN Health Services, но здесь больше проактивной составляющей (то есть рекомендации генерируются постепенно и еще до возникновения реальных проблем).

Для просмотра основных хэлсчеков сервера vCenter, нужно в vSphere Client пойти на вкладку Monitor и выбрать там раздел Health:

Чтобы эти фичи функционировали корректно, нужно чтобы у вас была включена настройка Customer experience improvement program (CEIP). Если вы не включили ее во время установки vCenter, то вы всегда можете сделать это в разделе Administration клиента vSphere Client:

Надо отметить, что vCenter Health Сhecks не только оповещает о проблемах виртуальной инфраструктуры, но и в некоторых случаях предоставляет ссылки на статьи базы знаний VMware KB, которые могут помочь найти решения.

Если вы нажмете на какой-нибудь из ворнингов, например, "Disk space check for VMware vCenter Server Appliance", то увидите две группы параметров на вкладках "Details" и "Info":

На вкладке Details отображены численные значения и/или объекты виртуальной инфраструктуры, имеющие отношение к предупреждению, а вот вкладка Info разъясняет его суть и дает рекомендации по его устранению. Если же в правом верхнем углу появился значок "Ask VMware", значит для данного предупреждения есть ссылка на статью базы знаний VMware KB, которая может помочь:

Например, здесь на двух из трех хостов ESXi установлена не последняя версия драйвера bnx2x (адаптер Broadcom NetXtreme II 10Gb):

На вкладке Info объясняется, что хосты с такой версией драйвера этого устройства могут вывалиться в "розовый экран":

Если нажмем "Ask VMware", то в новой вкладке откроется статья KB, описывающая проблемы данной версии драйвера и пути их решения:

Если вы сделали изменения конфигурации согласно рекомендациям, вы можете нажать кнопку RETEST в правом верхнем углу, чтобы увидеть только актуальные предупреждения:

Мы уже упоминали о политиках хранилищ SPBM, (Storage Policy Based Management) в кластере VMware vSAN, которые представляют собой очень гибкий механизм для выделения виртуальным машинам хранилищ с разными характеристиками, который работает на уровне отдельных виртуальных дисков.

Политики SPBM разделяются на 3 основных области:

• Storage Capabilities and Services - это политики, которые работают, когда хранилище vSAN или VVols представлено через интерфейс VASA производителем дисковой подсистемы (storage provider). Через VASA это устройство сообщает, какие сервисы оно предоставляет.
• Data Services - это политики, настраиваемые на уровне хоста ESXi, они также реализуются на стороне дискового устройства (storage provider). Эти политики не определяют размещение виртуальных машин, но влияют на их возможности, например, использование шифрования или механизма SIOC.
• Tags - это политики, которые используются хранилищами, которые не предоставляют каких-либо специфических функций, как правило - это обычные тома VMFS и NFS традиционных дисковых массивов без поддержки VASA.

В этой статье мы рассмотрим использование таких объектов, как тэги (Tags) и категории (Categories). Они могут оказаться полезными, когда вы хотите высокоуровнево определить параметры размещения и конфигурации виртуальных машин и их дисков на хранилищах, хостах, кластерах или в других объектах виртуальной инфраструктуры.

Поддержка правил на базе тэгов определяется при создании политики:

С помощью тэгов можно задать ярусы размещения ВМ, конфигурации дисков и их расположение, тип ОС, департамент, к которому принадлежит ВМ, тип дисков SAS/SATA/SSD и многое другое. Вот какие аспекты размещения внутри объектов виртуальной инфраструктуры можно контролировать через категории и тэги:

Например, вы хотите сделать так, чтобы виртуальные машины с гостевой ОС Linux попадали на определенные хранилища. В этом случае надо создать категорию "OS" для объектов Datastore и Datastore Cluster и тэг "Linux", который надо назначить заданным хранилищам. После этого машины с таким тэгом при выборе соответствующей политики SPBM будут попадать на заданные стораджи.

Так, например, может выглядеть конфигурация тэгов и категорий в вашей инфраструктуре:

В рамках одной политики можно использовать до 128 тэгов - это излишне, но если у вас есть фантазия, то вы можете использовать их все) Например, вы можете использовать категорию Department для отдела, а внутри создать тэги для всех отделов: Financial, HR, Engineering и т.п.

Категории и тэги можно использовать для разных аспектов конфигураций хранилищ. Например, тип ОС или тип дисков, на которых размещены ВМ (Category: Disk Type, Tag: SAS).

После создания тэга его нужно добавить к соответствующим датасторам и создать политику, которая использует соответствующие тэги. Это позволит определить размещение виртуальных машин при их создании, миграции или клонированию.

Весь этот процесс показан на видео ниже:

Еще одно преимущество такой механики заключается в том, что вы можете изменить хранилище, которое располагается под политикой, без изменения самой политики. То есть вы добавляете тэг какому-нибудь хранилищу, и оно автоматически попадает в политику с этим тэгом для размещения ВМ. Политику также можно ассоциировать с кластерами хранилищ (datastore clusters), что добавляет еще гибкости этому механизму.

Политики SPBM можно использовать не только отдельно для томов VMFS и NFS, но и для инфраструктуры vSAN и VVols, которые регулируются политиками на уровне хостов (host-based services). Например, можно создать политику, которая позволяет виртуальной машине использовать тома VVols, но только в определенном физическом размещении. Таким образом, с помощью провайдера VASA вы выбираете storage capability как VVols, а с помощью тэгов - физическое размещение ВМ.

Вот как это работает при создании политики:

С помощью PowerCLI вы можете получить информацию о виртуальных машинах или хранилищах, тэгированных определенным тэгом. Вот пример команды для ВМ:

Get-VM -Tag Windows

Name PowerState Num CPUs MemoryGB

---- ------- -------- --------

Windows-VMFS-VM PoweredOff 1 4.000

Win10-3 PoweredOn 2 4.000

jm-ws2016 PoweredOn 2 4.000

Win10-2 PoweredOn 2 4.000

И для хранилища:

Get-Datastore -Tag California

Name FreeSpaceGB CapacityGB

---- --------- ----------

N-VVol-Cali 2,048.000 2,048.000

При использовании механизмов размещения SPBM можно задавать уровень возможности их нарушения (Enforcement). Об этом вы можете прочитать в KB 2142765.

Несколько полезных ресурсов про политики SPBM:

• Storage Policy Based Management
• Populating the VM Storage Policies Interface
• Assign Tags to Datastores
• Storage DRS Integration with Storage Profiles

Уважаемые читатели! Некоторые из вас знают, что у нас на сайте есть цикл статей от Романа Гельмана, который разрабатывает различные функции своего PowerCLI-модуля Vi-Module. Они позволяют управлять многими аспектами виртуальной инфраструктуры VMware vSphere с помощью механизмов, недоступных в рамках стандартных средств управления.

Недавно Роман подал свой англоязычный блог ps1code.com на голосование по выбору лучшего блога о виртуализации Top vBlog 2018. И мы от лица всей редакции очень просим проголосовать за Романа - ведь его блог этого действительно достоин!

Спасибо вам заранее.

И вот статьи Романа на нашем ресурсе, чтобы вам удобнее было найти нужную функцию:

• PowerShell скрипт для автоматической установки ESXi хостов на серверах IBM/Lenovo
• Как получить расширенную информацию об RDM-дисках с помощью PowerCLI
• Как конвертировать «тонкие» VMDK-диски в Eager Zeroed Thick с помощью VMware PowerCLI
• Как найти хост ESXi с виртуальными машинами VMware vCenter и SQL Server, когда они выключены?
• Команда Connect-VIServer в PowerCLI: глубокое погружение или «куда же я подключен?»
• Как скопировать VMware ВМ Notes в Computer/AD Computer Account description
• Как узнать версию BIOS/Firmware ESXi сервера при помощи PowerCLI
• Как узнать дату и время установки хоста ESXi
• Как сравнить установленные VIB packages между двумя и более хостами ESXi
• Как включить/отключить SSH на всех хостах ESXi в кластере при помощи PowerCLI
• Как задать/изменить NTP-серверы для хостов ESXi с помощью PowerCLI
• Как узнать версию любого объекта VMware? Используйте Get-Version!
• Azure Automation: как включить/выключить ВМ в облаке Microsoft Azure по расписанию
• Автоматизация работы с тегами Azure VM
• Как найти потерянные VHD файлы в облаке Azure IaaS?
• Как просматривать датасторы VMware с помощью PowerCLI
• Как сравнить 2 или более хостов VMware ESXi с помощью PowerCLI
• Как мигрировать VMware VM Templates на другой Datastore с помощью PowerCLI
• PowerShell и putty – лучше вместе
• Как получить информацию о графическом процессоре ESXi с помощью PowerCLI
• Как проверить наличие хотфикса в VMware ВМ с помощью PowerCLI
• Как конфигурировать Storage DRS кластеры с PowerCLI – Часть 1
• Как создавать и удалять SDRS Anti-Affinity правила с PowerCLI – Часть 2
• Как конфигурировать SDRS Anti-Affinity правила с PowerCLI – Часть 3
• Как увеличить VM Guest Partition с помощью PowerCLI
• Сохранять и извлекать учетные данные с помощью PowerCLI
• Как узнать срок годности резервных копий vCSA с помощью PowerCLI?
• Как получить данные CDP протокола с помощью PowerCLI
• Как мониторить задачи Nutanix с PowerShell

Голосуйте за Романа и его ps1code.com!

Мы уже публиковали ссылки для скачивания всех сессий конференции VMware VMworld 2018, которая прошла этим летом. На прошлой неделе закончилась и европейская часть этой конференции - VMworld Europe 2018, об анонсах которой мы писали тут и тут.

Ну а недавно стали доступны записи почти всех сессий с европейского VMworld (369 из 389), ссылки на которые добрый человек занес в Excel-таблицу:

Скачать сессии в Linux-машинах можете каким удобно способом:

• WGET:

wget --no-check-certificate --referer https://videos.vmworld.com/global/2018/videoplayer/26950 https://s3.us-east-2.amazonaws.com/vmworld-europe-2018/MGT3918BE.mp4

• CURL:

curl --referer https://videos.vmworld.com/global/2018/videoplayer/26950 https://s3.us-east-2.amazonaws.com/vmworld-europe-2018/MGT3918BE.mp4 -O MGT3918BE.mp4

• PowerCLI:

$headers = @{"referer" = "https://videos.vmworld.com/global/2018/videoplayer/26950"}
Invoke-WebRequest -Uri "https://s3.us-east-2.amazonaws.com/vmworld-europe-2018/MGT3918BE.mp4" -Headers $headers -Outfile MGT3918BE.mp4

Как вы все знаете, в Лас-Вегасе недавно закончилась главная конференция года о виртуализации VMware VMworld 2018. Мы опубликовали несколько статей о новых продуктах и технологиях, анонсированных там, но многие хотели бы посмотреть какие-то отдельные сессии с конференции.

Такая возможность есть - вы можете скачать все сессии VMworld 2018 одним torrent-файлом, в котором файлов для загрузки аж на 802 ГБ! Там вы можете выбрать для скачивания только интересующие вас сессии (за торрент спасибо Wojciech Marusiak):

Также вы можете посмотреть все сессии онлайн (без их загрузки) или скачать какие-то отдельные по ссылкам от Вильяма Лама, который разместил их на GitHub:

Также если что-то произойдет с проектом Лама, есть вот такой репозиторий со ссылками на mp4-файлы с записями сессий VMworld 2018 от Jorge de la Cruz.

Иногда бывает, что администратору платформы VMware vSphere требуется выгрузить список всех миграций vMotion виртуальных машин, которые произошли между хостами ESXi в последнее время, а также миграций Storage vMotion между хранилищами.

Для vMotion и SVMotion есть вот такой скрипт от Luc Dekens, который экспортирует миграции за указанное число часов или дней в файл XLS. Запустить его можно такой командой (скрипт точно работает для vSphere 6.5, как пишут здесь):

get-motionhistory -Entity (get-cluster "Cluster 1" | get-vm) -Days 2 | Export-csv -NoTypeInformation -UseCulture E:\VMware\Prod_vMotions.csv

На выходе будет вот такая табличка (обратите внимание, что миграции поделены на пользовательские и системные от DRS/SDRS, а также в поле Type указано, что это - vMotion или SVMotion):

Также ребята из компании Opvisor несколько адаптировали этот скрипт в разрезе миграций хранилищ Storage vMotion для подсчета общего объема миграций и выложили его тут. Работа этого скрипта дает вот такой результат:

7 лет назад мы писали про утилиту ESXi-Customizer, которая позволяет добавлять кастомные драйвера в ISO-образ VMware ESXi. У того же автора (Andreas Peetz) есть еще одна замечательная утилита, которая актуальна и на сегодняшний день - ESXi-Customizer-PS. Актуальна - это значит, что ее последняя версия (от 18 апреля этого года) поддерживает последние версии платформ и фреймворка - vSphere 6.7 и PowerCLI 10.

ESXi-Customizer-PS - это PowerShell-скрипт, который на входе принимает большое число различных параметров, а на выходе дает кастомизированный ISO-образ или офлайн-бандл ESXi:

Сценарий имеет три режима работы:

• Создать установочный образ ISO или Offline Bundle напрямую из хранилища VMware Online depot (стандартный режим).
• Создать установочный образ ISO или Offline Bundle из скачанного ESXi Offline Bundle (параметр -izip).
• Обновление локального ESXi Offline Bundle с помощью ESXi patch bundle из хранилища VMware Online depot (параметры -izip -update).

С помощью этих трех режимов вы можете добавлять бандлы из хранилища V-Front Online Depot, либо любого другого Online Depot, указав его URL, а также можно указывать локальные Offline Bundles и VIB-файлы (собственно, кастомные драйверы или кастомный софт под ESXi).

Об использовании утилиты ESXi-Customizer-PS Alex Lopez снял хороший видеотуториал:

Скрипт можно использовать множеством способов. Давайте рассмотрим основные:

1. Вызов скрипта без параметров.

Например:

.\ESXi-Customizer-PS-v2.6.0.ps1

В этом случае утилита создаст ISO-образ ESXi самой последней версии (6.7 на данный момент) и с самым последним уровнем обновлений. Вы также можете указать конкретный номер версии ESXi, для которой будет получен ISO с последними обновлениями. Например:

• -v50 : ESXi 5.0 ISO
• -v51 : ESXi 5.1 ISO
• -v55 : ESXi 5.5 ISO
• -v60 : ESXi 6.0 ISO
• -v65 : ESXi 6.5 ISO
• -v67 : ESXi 6.7 ISO

Также есть еще три параметра:

• -outDir : записывать ISO-образ в указанную директорию.
• -sip : не использует последний уровень патчей, а показывает меню, где можно выбрать конкретный патч. Новые патчи будут показаны сверху. Также будут показаны и профили, которые содержат только обновления безопасности и/или VMware Tools.
• -ozip : на выходе будет сформирован не ISO, а ESXi Offline Bundle, который можно импортировать в Update Manager, указать вручную для обновления черезesxcli или использовать как входной бандл для следующих кастомизаций.

2. Использование офлайн бандла ESXi Offline Bundle как входного параметра (вместо VMware Online depot).

Например, такая команда позволит вам получить ISO-образ из офлайн-бандла:

.\ESXi-Customizer-PS-v2.6.0.ps1 -izip .\VMware-ESXi-6.0.0-2494585-depot.zip

Офлайн бандл можно скачать через VMware Patch Download portal. Некоторые вендоры также предлагают свои кастомизированные офлайн-бандлы, например HP. Офлайн бандлы VMware можно найти вот тут. Также вы можете использовать параметры из пункта 1.

3. Добавление дополнительных пакетов из присоединенных хранилищ Online depots.

Например, вот эта команда позволит добавить сетевые драйверы, отсутствующие в образе ESXi 5.5:

.\ESXi-Customizer-PS-v2.6.0.ps1 -v55 -load net-r8168,net-r8169,net-sky2

Данные драйверы есть в VMware Online depot, так как они есть в составе ESXi 5.0 и 5.1, но были исключены из дистрибутива ESXi 5.5. Важно, что для ESXi 6.0 такая штука для этих драйверов уже не прокатит, так как они были добавлены в черный список (blacklised).

4. Присоединение онлайн-хранилища V-Front Online Depot и других хранилищ.

Делается это следующей командой:

.\ESXi-Customizer-PS-v2.6.0.ps1 -v60 -vft -load sata-xahci,net55-r8168

В результате в образ ESXi 6.0 будут добавлены драйверы из V-Front Online Depot (sata-xahci и net55-r8168).

5. Добавление локальных офлайн-бандлов и VIB-файлов.

Вот такая команда добавит все офлайн-бандлы и VIB-пакеты в последний образ ESXi 6.7:

.\ESXi-Customizer-PS-v2.6.0.ps1 -pkgDir C:\temp\pkg

Этой командой вы сможете добавить драйверы типа 3rd party или community supported.

6. Обновление локальных офлайн-бандлов.

Вот такая команда обновит ESXi 6.0 Offline bundle последними патчами из онлайн-хранилища VMware:

.\ESXi-Customizer-PS-v2.6.0.ps1 -v60 -izip .\VMware-ESXi-6.0.0-2494585-HP-600.9.1.39-Mar2015-depot.zip -update

Здесь надо не забывать указывать номер версии патчируемого гипервизора (в данном случае -v60 - это ESXi 6.0).

7. Расширенные параметры.

У утилиты есть еще несколько расширенных параметров, которые дают еще больше возможностей по кастомизации образов ESXi:

• -log : указание пути к кастомному лог-файлу.
• -test : тестирование возможности построения или обновления образа без накатывания реальных изменений. Экономит массу времени, так как не перестраивает ISO или zip, а также не качает обновления и образы из VMware Online depot.
• -nsc : это опция -noSignatureCheck, которая отключает проверку сигнатуры при выполнении функции экспорта. Ее нужно использовать, если вы получаете ошибку типа "Could not find trusted signer." (пакет с некорректными или отсутствующими сигнатурами).
• -ipname, -ipdesc, -ipvendor: задание собственных атрибутов в профиле образа. По умолчанию в имени и описании останутся прежние значения с приставкой "customized", а имя вендора не изменится.
• -remove vib1[,...]: удаление одного или нескольких VIB-пакетов из кастомного образа.

Скачать ESXi-Customizer-PS-v2.6.0.ps1 можно по этой ссылке.

Мы иногда пишем о том, что большие обновления как хост-серверов VMware ESXi, так и управляющих компонентов VMware vCenter / vCenter Server Appliance всегда лучше ставить заново, а не делать апгрейд с предыдущих версий (если у вас, конечно, есть такая возможность). Да, вы не сохраните логи и исторические данные, но это позволит вам избежать различных проблем, связанных с устаревшими компонентами, которые останутся при обновлении и могут вступить в конфликт с новыми функциями при определенных обстоятельствах.

Такой вот пример приводит и Mike Foley в статье про механизм безопасной загрузки хостов vSphere Secure Boot. Когда он обновил свою инфраструктуру на VMware vSphere 6.7 с версии 6.5, он решил проверить функции Secure Boot и возможности модуля TPM 2.0.

Но когда он включил эти возможности в UEFI BIOS, он получил "розовый экран смерти" (PSOD) сервера ESXi:

Причина оказалась проста - для некоторых legacy-драйверов при обновлении не были обновлены их сигнатуры для VIB-пакетов, поэтому механизм Secure Boot не может эти сигнатуры проверить и выводит хост в PSOD при загрузке.

Чтобы найти эти драйверы, он запустил скрипт secureBoot.py, который показывает модули, препятствующие безопасной загрузке:

/usr/lib/vmware/secureboot/bin/secureBoot.py -c

Вывод оказался примерно таким:

[root@esxi-117] /usr/lib/vmware/secureboot/bin/secureBoot.py -c Secure boot CANNOT be enabled: 

Failed to verify signatures of the following vib(s): [

net-tg3 

dell-configuration-vib 

net-i40e 

net-igb 

net-ixgbe 

vmware-esx-perccli-1.05.08 

ima-qla4xxx 

misc-cnic-register 

net-bnx2 

net-bnx2x 

net-cnic 

net-qlcnic 

net-qlge 

scsi-bnx2fc 

scsi-bnx2i 

scsi-qla4xxx 

scsi-megaraid-sas 

lsu-lsi-mptsas-plugin].

All tardisks validated. All acceptance levels validated

Посмотрев на каждый драйвер по отдельности, он понял, что все это старые Linux-драйверы, которые были заменены в новых версиях VMware vSphere своими Native-аналогами. Например, для драйвера net-tg3 есть аналогичный нативный драйвер ntg3, а для net-bnx2i есть bnxnet.

Поэтому далее Майк просто удалил все VIB-пакеты со старыми драйверами следующей командой:

esxcli software vib remove -n scsi-megaraid-sas

esxcli software vib remove -n net-tg3

esxcli software vib remove -n net-i40e

esxcli software vib remove -n net-igb

esxcli software vib remove -n net-ixgbe

esxcli software vib remove -n net-qlcnic

esxcli software vib remove -n scsi-bnx2i

esxcli software vib remove -n scsi-bnx2fc

esxcli software vib remove -n net-bnx2x

esxcli software vib remove -n scsi-qla4xxx

esxcli software vib remove -n net-cnic

esxcli software vib remove -n net-bnx2

esxcli software vib remove -n net-qlge

esxcli software vib remove -n misc-cnic-register

esxcli software vib remove -n lsu-lsi-mptsas-plugin

esxcli software vib remove -n ima-qla4xxx

esxcli software vib remove -n vmware-esx-perccli-1.05.08

esxcli software vib remove -n dell-configuration-vib

В итоге его хост смог безопасно загрузиться через Secure Boot. Также Майк далее в статье рассматривает решение еще одной специфической проблемы, которая встречается довольно редко.

Ну а мы еще раз напомним - если есть возможность поставить новую мажорную версию ESXi с нуля - лучше скачайте ISO-образ и сделайте это, вместо того, чтобы "быстро и безопасно" обновиться на новую версию.

Некто Bery Ju разработал интересный плагин к браузеру - темную тему для консоли VMware vSphere HTML5 Client, которая называется dark-vcenter (кстати, некоторое время назад темный режим уже был в клиенте, но его убрали). Эта тема работает для платформ VMware vSphere версий 6.5 и 6.7 под браузеры Google Chrome и Mozilla Firefox.

Это всего лишь CSS-тема для браузера, которая применяется, когда вы заходите на сервер vCenter через vSphere Client. В этом случае плагин автоматически подхватывает клиента. Ничего на самом сервере vCenter при этом не меняется.

Тема, конечно, на любителя - у многих, например, от темных фонов болят глаза. Но если кто-то работает с клиентом vSphere Client в темноте, почти без освещения, такая тема вполне может пригодиться.

Сайт проекта на GitHub: https://github.com/BeryJu/dark-vcenter

Помните, что для установки плагина в Google Chrome у вас должен быть включен Developer mode в браузере.

На днях компания VMware обновила свое средство для управления виртуальной инфраструктурой на базе технологии HTML5 - на сайте проекта VMware Labs появился VMware vSphere Client версии 3.36.

Напомним, что о версии 3.34 этого продукта мы писали в середине февраля вот тут, поэтому давайте взглянем на новые функции и улучшения последних двух версий клиентов - VMware vSphere Client 3.36 и 3.35:

• Кастомизация дополнительных устройств и опций при создании виртуальной машины или ее клонировании:
• Host USB device
• SCSI controller
• USB controller
• SATA controller
• CPU > CPUID Mask > Advanced
• VM Options > VMRC options
• VM Options > VMware Tools > Power Operations
• VM Options > Power Management > Wake up on LAN
• VM Options > Advanced Configuration Parameters
• VM Options > Fibre Channel NPIV
• Оповещение перед тем, как происходит операция над шаблоном ВМ, который в данный момент управляется клиентом.
• Улучшения интерфейса для быстрого поиска (Quick search).
• Улучшения в панели управления дисками ВМ - теперь они объединяются в группы в разделе VM Summary->Edit Settings (если их больше 4 штук).
• Несколько исправлений багов и мелких улучшений.

Скачать VMware vSphere Client 3.36 можно по этой ссылке.

На сайте nolabnoparty.com появилась отличная статья о том, как нужно выключать и включать кластер отказоустойчивых хранилищ VMware vSAN таким образом, чтобы не повредить данных, и включить его потом без особых проблем. Инструкция может оказаться полезной тем администраторам, которым необходимо остановить кластер vSAN целиком в целях обслуживания оборудования (серверы, коммутаторы, стойка и т.п.).

Выключение кластера vSAN

1. Для начала вам нужно выключить все виртуальные машины, кроме сервера VMware vCenter (неважно, обычный это VC или vCSA):

2. Мигрируем с помощью vMotion сервер vCenter на хост ESXi01 (тот хост, который вы считаете своим первым хостом в виртуальной инфраструктуре):

Также на первый хост ESXi настоятельно рекомендуется перевести контроллер домена Active Directory.

3. Теперь надо убедиться, что в данный момент в кластере vSAN нет процессов ресинхронизации (Resyncing Components). Для этого надо зайти в соответствующий раздел на вкладке Monitor:

На этом скриншоте видно, что никаких процессов ресинхронизации сейчас не идет. Если они у вас есть, то следует дождаться их завершения.

4. Переводим все хосты VMware ESXi (кроме ESXi01) в режим обслуживания (Maintenance Mode):

В настройках режима обслуживания уберите галку с варианта переместить машины (Move powered-off and suspended virtual machines...), а также выберите вариант не перемещать данные кластера vSAN (No data evacuation):

5. Выключите гостевую ОС виртуальной машины c VMware vCenter. Для этого в контекстном меню vCenter или vCSA выберите пункт Shut Down Guest OS:

После этого у вас, само собой, отпадет соединение с VMware vSphere Web Client:

6. Зайдите на хост ESXi через ESXi Host Client (ссылка https://<ip esxi>/ui) и переведите сервер в режим обслуживания, выбрав из контекстного меню пункт Enter maintenance mode:

Аналогично укажите, что не нужно переносить данные кластера vSAN:

Также это можно сделать следующей командой esxcli в консоли сервера:

# esxcli system maintenanceMode set -e true -m noAction

Включение кластера VMware vSAN

1. Сначала последовательно выводим хосты ESXi из режима обслуживания, начав с первого:

Сделать это также можно командой esxcli:

# esxcli system maintenanceMode set -e false

2. Включаем на хосте ESXi01 сервер vCenter и контроллер домена Active Directory:

3. Идем на вкладку Monitor и там в разделе Health убеждаемся, что все узлы в порядке и кластер vSAN прошел все проверки:

4. Только после этого включаем все виртуальные машины: